The location service of a mobile communications network is to obtain the location information of target UE by means of positioning techniques, where the target UE refers to a user terminal in a mobile communication network to be positioned and the location information may be the geographical information expressed in latitude and longitude data or the location information with reference to local streets. The location information obtained by an LCS system may be provided for the user that uses the target UE for self-positioning, for the communication system itself for use in area-specific charging or operational maintenance, or for other clients, for instance, agencies or individuals, requesting the location information of the target UE for use in value-added services. Therefore, location service has wide applications in such fields as contingency rescue, vehicle navigation and intelligent traffic system, job control and team management, mobile yellow page query, and enhanced network performance. In 3GPP, specifications of LCS as well as the operational mode, structure, state description, and message flow for LCS implementation have been put forward.
FIG. 1 is a schematic showing the logical structure of the LCS functions. As shown in FIG. 1, in terms of functional logics, implementation of LCS involves LCS client 101, LCS system 107 that contains functions for implementing LCS, and target UE 108. Functions for implementing LCS include gateway mobile location center (GMLC) 102, user data storage server (HLR/HSS) 103, core network (CN) 104, radio access network (RAN) 105, and privacy profile register (PPR) 106. LCS client 101 comprises LCS clients and LCS clients. The LCS client refers to a software or hardware entity interfaced with GMLC 102 for use in obtaining the location information of one or more target UE 108. The LCS client refers to an application client, such as an agency or an individual, requesting the location information of a target UE, and is the initiator of a request for location information. An LCS client may be a LCS client at the same time. GMLC 102 provides a standard LCS interface for information interaction between the LCS client and functions implementing LCS to handle relevant messages of LCS, for instance, privacy check for LCS client 101 as well as privacy check for the location request sent by LCS client 101. In addition, GMLC 102 may request that PPR 106 which has stored the privacy data of target UE 108 makes privacy check for the location request sent by LCS client 101. After a successful privacy check, GMLC 102 makes a request to CN 104 for the location of target UE 108, CN 104 locates target UE 108 in coordination with RAN 105 and sends the location result of target UE 108 to GMLC 102, and finally GMLC 102 is responsible for sending the location result of target UE 108 to LCS client 101. HLR/HSS 103 is used to store user data and provide relevant information of target UE 108 for other logics of the network, for instance, the home GLMC of target UE 108, the current GMLC target UE 108 is visiting, and the address information of CN 104.
GMLC 102 may further include requesting GMLC (R-GMLC), home GMLC (H-GMLC), and visited GMLC (V-GMLC). R-GMLC is the GMLC receiving the location request for target UE 108 initiated by LCS client 101, H-GMLC is the home GMLC to which target UE 108 belongs, and V-GMLC is the GMLC target UE 108 is currently visiting, that is, the GMLC where target UE currently is. R-GMLC, H-GMLC, and V-GMLC may belong to the same public land mobile network (PLMN), or belong to different PLMNs. When R-GMLC, H-GMLC, and V-GMLC belong to the same PLMN, they may comprise one physical entity or different physical entities.
At present, in the LCS specifications of 3GPP, location requests for target UE from LCS clients are classified into two categories: immediate location requests and deferred location requests. With an immediate location request, the LCS system will immediately locate the target UE after receiving a location request for the target UE from a LCS client, and immediately send the location information to the LCS client, that is, the LCS system, after receiving a location request sent by a LCS client, will immediately provide the LCS client with the information of current location of the target UE. With a deferred location request, the LCS client requests that the LCS system provide it with the location information of a target UE at a future moment or when a specific event has occurred, that is, after receiving a location request for a target UE from a LCS client, the LCS system will wait for a deferred period of time till the triggering of a deferred event to provide the LCS client with the current location information of the target UE. The LCS specifications of 3GPP allow a LCS client to request that the LCS system periodically provide it with the location information of a target UE, that is, the LCS client may define the starting time and ending time as well as a certain periodical logic to request the LCS system provide it with the location information of target UE within the time period in accordance with the periodical logic. A periodical request for location information can be regarded as a deferred location request. In the LCS specifications of 3GPP, deferred location requests are further classified into two types, UE available event location requests and change of area event location request.
With a UE available event location request, the LCS client will designate in advance a certain action of the target UE as the triggering event, for instance, when the target UE switches on and gets attached with the network, the LCS system will locate the target UE and returns the location result thereof. In this case, the LCS system saves the triggering event in CN, which monitors the action of the target UE; once it is detected that the action of the target UE satisfying the triggering event has occurred, CN will locate the target UE in coordination with RAN and the location result thereof is returned to the LCS client via GMLC.
With a change of area event location request, the LCS client will designate in advance a target area and events for triggering LCS reports, for instance, the target UE submits to the LCS client LCS area event reports when the target LIE enters, leaves, or is located at the designated target area, in this case, the LCS sends to the target UE the information of the designated target area and events for triggering LCS reports, and the target UE saves the information thereof and initiates at the same time the appropriate application program. When the application program detects the occurrence of an event for triggering LCS reports, for instance, the target UE has entered, left, or been located in the designated target area, the target UE will submit to the LCS system a LCS area event report, and the LCS system will forward to the appropriate LCS client this LCS area event report, informing the LCS client that the event which has been designated for triggering LCS report has occurred.
At present, the LCS specifications of 3GPP have defined the process for a LCS client or LCS system to initiate cancellation of a deferred location request currently in activated state. A detailed description of the process for canceling a deferred location request is given as follows.
FIG. 2 shows the flowchart of canceling a UE available event location request. As shown in FIG. 2, the implementation of canceling a UE available event location request comprises the steps of:
Steps 201-202: The LCS client sends to R-GMLC an LCS Cancel Service Request carrying an identification of UE available event location request; after receiving the LCS Cancel Service Request, R-GMLC forwards this request to H-GMLC.
In addition, when the LCS system determines that the valid period of a UE available event location request has ended, it is needed to end the handling of this UE available event location request. Since relevant information of the location request for target UE from a LCS client, such as the valid time period of the location request, is stored in R-GMLC of the LCS system, R-GMLC is able to determine the UE available event location request that is needed to end according to the above information. R-GMLC then needs to notify the other functions in the LCS system to end the handling of this UE available event location request. At this moment, R-GMLC initiates the cancellation procedure to the UE available event location request that is needed to end. So, for canceling a UE available event location request, R-GMLC will directly send to H-GMLC an LCS Cancel Service Request carrying the identification of a UE available event location request.
Step 203: after receiving the LCS Cancel Service Request carrying the identification of a UE available event location request, H-GMLC forwards this LCS Cancel Service Request to V-GMLC.
Steps 204-205: after receiving the LCS Cancel Service Request carrying the identification of a UE available event location request, V-GMLC sends to CN a request of canceling locating target UE with Provide Subscriber Location message carrying the identification of a UE available event location request; CN, after receiving this Provide Subscriber Location message, deletes self-stored relevant information of the appropriate UE available event location request, and then sends to V-GMLC a Provide Subscriber Location ACK.
Step 206: after receiving the Provide Subscriber Location ACK, V-GMLC sends to H-GMLC an LCS Cancel Service Response, notifying H-GMLC that the appropriate UE available event location request has been canceled.
Steps 207-208: after receiving the LCS Cancel Service Response, H-GMLC deletes the saved relevant information of the appropriate UE available event location request, ends the handling of this location request, and sends to R-GMLC the LCS Cancel Service Response, notifying R-GMLC that the appropriate UE available event location request has been canceled. After receiving the LCS Cancel Service Response, R-GMLC deletes the saved relevant information of the appropriate UE available event location request, ends the handling of this location request, and sends to the LCS client the LCS Cancel Service Response, notifying the LCS client that the appropriate UE available event location request initiated by the LCS client has been canceled.
FIG. 3 shows the flowchart of canceling a change of area event location request. As shown in FIG. 3, the process for canceling a change of area event location request comprises the steps of:
Steps 301-302: the LCS client sends to R-GMLC an LCS Cancel Service Request carrying the identification of a change of area event location request; after receiving the LCS Cancel Service Request, R-GMLC forwards this request to H-GMLC.
In addition, when the LCS system determines that the valid period of a change of area event location request has ended, it is needed to end the handling of this change of area event location request. Since relevant information of the location request for target UE from a LCS client, such as the valid time period of a location request, is stored in R-GMLC of the LCS system, R-GMLC is able to determine the change of area event location request that is needed to end according to the above information. R-GMLC then needs to notify the other functions in the LCS system to end the handling of this change of area event location request. At this moment, R-GMLC initiates the cancellation procedure to the change of area event location request that is needed to end. So, for canceling a change of area event location request, R-GMLC will directly send to H-GMLC an LCS Cancel Service Request carrying the identification of a change of area event location request.
Step 303: after receiving the LCS Cancel Service Request carrying the identification of a change of area event location request, H-GMLC forwards this LCS Cancel Service Request to V-GMLC.
Steps 304-305: after receiving the LCS Cancel Service Request carrying the identification of a change of area event location request, V-GMLC sends to CN a Provide Subscriber Location carrying the identification of a change of area event location request; CN, after receiving this Provide Subscriber Location message, sends to the target UE via RAN an LCS Area Event Cancel carrying the identification of a change of area event location request, notifying the target UE to delete the stored relevant information of this change of area event location request.
Steps 306-308: after receiving the LCS Area Event Cancel, the target UE sends to CN via RAN an LCS Area Event Cancel ACK, notifying CN that the LCS Area Event Cancel sent by CN has been received, deletes the self-stored relevant information of the appropriate change of area event location request in accordance with the identification of a change of area event location request, and then sends to CN an LCS Area Event Report[Cancel], notifying CN that the stored relevant information of the appropriate change of area event location request has been deleted. After receiving the LCS Area Event Report [Cancel], CN sends to V-GMLC a Provide Subscriber Location ACK, notifying V-GMLC that the appropriate change of area event location request has been canceled.
Steps 309-311: after receiving the Provide Subscriber Location ACK, V-GMLC sends to H-GMLC an LCS Cancel Service Response, notifying H-GMLC that the change of area event location request has been canceled. After receiving the LCS Cancel Service Response, H-GMLC deletes the saved relevant information of the appropriate change of area event location request, ends the handling of this location request, and sends to R-GMLC the LCS Cancel Service Response, notifying R-GMLC that the appropriate change of area event location request has been canceled. After receiving the LCS Cancel Service Response, R-GMLC deletes the saved relevant information of the appropriate change of area event location request, ends the handling of this location request, and sends to the LCS client the LCS Cancel Service Response, notifying the LCS client that the appropriate change of area event location request initiated by the LCS client has been canceled.
In practical applications, a target UE may update its own privacy profile, for instance, a target UE may modify the access code of location request from a LCS client, or cancel the authorization for a LCS client to locate it. The privacy profile of a target UE is stored in PPR, which can be an independent entity or integrated in GMLC. If PPR is integrated in GMLC, GMLC will be able to be aware directly that the privacy profile of a target UE has changed when the privacy profile thereof has been updated. If PPR is an independent entity, when the privacy profile of a target UE changes, PPR will inform GMLC by the following process that the privacy profile of the target UE has been updated, as shown in FIG. 4:
Steps 401-402: PPR sends to GMLC an LCS Privacy Profile Update Notification carrying the identity of the target UE, notifying GMLC that the privacy profile of the target UE has changed. After receiving the LCS Privacy Profile Update Notification, GMLC returns to PPR an LCS Privacy Profile Update Notification ACK, notifying PPR that the LCS Privacy Profile Update Notification sent by PPR has been received.
Although in the LCS specifications of 3GPP there is the definition that the LCS system may cancel a deferred location request in activated state affected by the update of privacy profile of the target UE after the LCS system is aware of the update thereof, the LCS system is unable to determine which deferred location requests currently in activated state will be affected by the update of privacy profile of the target UE because there is no appropriate handling process put forward in the LCS specifications of 3GPP, thus it is impossible to make cancellation procedure to these deferred location requests.